This section is intended to provide a background or context to the invention. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived, implemented or described. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The following abbreviations that may be found in the specification and/or the drawing figures are defined as follows:    AC access control    ACL access control list    AD analog-to-digital    CM coexistence manager    CR cognitive radio    DA digital-to-analog    DB data base    DCA digital signature algorithm    DIMM dual in-line memory module    DMZ demilitarized zone (perimeter networking)    DRAM dynamic random access memory    ECC elliptic curve cryptography    ID identification, identifier    JEDEC joint electron device engineering council    MMCO memory module controller    MRAM magnetic random access memory    NFC near field communication    NVM non-volatile memory    OS operations system    OTP one time programmable    PDA personal digital assistant    PCM phase change memory    RAM random access memory    RF radio frequency    RSA Rivest Shamir Adleman    R/O read only    R/W read/write    SDRAM, synchronous dynamic random access memory    SLDRAM synchronous-link DRAM    SIMM single in-line memory module    SPI serial peripheral interface (bus) SRAM static random access memory    SW software    TCM tightly coupled memory    UE user equipment
Typical operation in an operating systems (OS) with access control in the operating system layer, when launching an application follows normally the following steps:
1) Process forks;
2) One of the processes asks the kernel/loader to launch a new executable;
3) The “to be loaded” binary code is read from the disk/flash and “measured”;
4) The measurement is an input to the access enforcement policy; and
5) The binary code on the flash is “locked” for the duration of the execution with no R/W is allowed. This is e.g. to enable on-demand code page loading.
In fact, file locking is also used with OSs without access control just to enable on-demand loading of code pages as demonstrated in FIG. 1. In such cases the positional integrity of the code (and protection against deletion) is the sought-after property.
Executable protection is a form of file locking, and there are many ways of achieving that property. For example, modern versions of Linux deals with open files with reference counts, and an already running program can (seemingly) be changed, since the already running code instance is stored elsewhere until its execution terminates.
In all cases, however, this kind of file locking happens at device run-time, and is managed by the memory-based file system. It is assumed that all non-volatile memory accesses happen through the file system, and thus the locking can be enforced. The same may hold for network file systems, although the entry driver points are distributed.